Alex Crichton [Wed, 11 Jul 2018 16:27:08 +0000 (09:27 -0700)]
Partially revert dep changes in #5651
Some logic which was tweaked around the dependencies of build script targets was
tweaked slightly in a way that causes cargo to stack overflow by accientally
adding a dependency loop. This commit implements one of the strategies discussed
in #5711 to fix this situation.
The problem here is that when calculating the deps of a build script we need the
build scripts of *other* packages, but the exact profile is somewhat difficult
to guess at the moment we're generating our build script unit. To solve this the
dependencies towards other build scripts' executions is added in a different
pass after all other units have been assembled. At this point we should know for
sure that all build script executions are in the dependency graph, and we just
need to add a few more edges.
bors [Fri, 29 Jun 2018 22:26:44 +0000 (22:26 +0000)]
Auto merge of #5671 - Mark-Simulacrum:backport-4be5a4486, r=alexcrichton
Fix avoiding a rebuild when moving around a workspace
This is a backport of https://github.com/rust-lang/cargo/pull/5669.
There's a case where Cargo will recompile a project even if the fingerprint
looks like it's fresh, when some output files are missing. This was intended to
cover the case where an output file was deleted manually or otherwise messed
with. The check here was a bit too eager, however. It checked not only the
actual output destination of the compiler but *also* the location that we hard
link the output file up to.
Due to recent changes in #5460 we don't always create the hard links for path
dependencies in the top-level dir, and this meant that if the library were
compiled and then tested later on the test may recompile the original library by
accident.
The fix in this commit is to cease looking for the hardlink if it exists or not.
This way we only check for the presence of the output file itself and only
recompile if that file is missing. The reason for this is that we
unconditionally relink files into place whether it's fresh or not, so we'll
always recreate the hard link anyway if it's missing.
Alex Crichton [Fri, 29 Jun 2018 19:17:41 +0000 (12:17 -0700)]
Fix avoiding a rebuild when moving around a workspace
There's a case where Cargo will recompile a project even if the fingerprint
looks like it's fresh, when some output files are missing. This was intended to
cover the case where an output file was deleted manually or otherwise messed
with. The check here was a bit too eager, however. It checked not only the
actual output destination of the compiler but *also* the location that we hard
link the output file up to.
Due to recent changes in #5460 we don't always create the hard links for path
dependencies in the top-level dir, and this meant that if the library were
compiled and then tested later on the test may recompile the original library by
accident.
The fix in this commit is to cease looking for the hardlink if it exists or not.
This way we only check for the presence of the output file itself and only
recompile if that file is missing. The reason for this is that we
unconditionally relink files into place whether it's fresh or not, so we'll
always recreate the hard link anyway if it's missing.
bors [Thu, 7 Jun 2018 07:02:02 +0000 (07:02 +0000)]
Auto merge of #5603 - matklad:publish-nightly-features, r=matklad
Allow publishing crates with nightly features
closes #5427.
cc @rust-lang/cargo: I remember a vigorous debate over publishing crates with nightly Cargo features, but I can't recollect our exact plan of action. The discussion is logged here: https://paper.dropbox.com/doc/Unstable-Cargo-features-JBYMdsUYcO3FyW8Ubkjoz.
I think we just need to allow to publish crates with unstable cargo features, for the same reason we allow unstable rust features: you need explicit opt-in, even for deps. This is covered by Cargo tests: https://github.com/rust-lang/cargo/blob/9f097787b04b06cdde4fc42b26a531b22c1b37a6/tests/testsuite/cargo_features.rs#L115-L215.
I am not sure if we have ever implemented crates.io side of validation?
bors [Sat, 2 Jun 2018 18:24:26 +0000 (18:24 +0000)]
Auto merge of #5506 - ehuss:config-profile, r=alexcrichton
Config Profiles (RFC 2282 Part 2)
Notes:
- `-Z config-profile` CLI option is required to use.
- Config values no longer reject mixed base types (integer, string, boolean) in order to support the mixed types in profiles.
Eric Huss [Sun, 6 May 2018 22:14:46 +0000 (15:14 -0700)]
Config Profiles (RFC 2282 Part 2)
Notes:
- `-Z config-profile` CLI option is required to use.
- Config values no longer reject mixed base types (integer, string, boolean) in order to support the mixed types in profiles.
bors [Wed, 30 May 2018 20:12:02 +0000 (20:12 +0000)]
Auto merge of #5552 - ehuss:config-serde, r=alexcrichton
Typed Config Access
This introduces a new API for accessing config values using serde to
automatically convert to a destination type. By itself this shouldn't
introduce any behavioral changes (except for some slight wording changes to
error messages). However, it unlocks the ability to use richer data types in
the future (such as `profile`, or `source`). Example:
```rust
let p: Option<TomlProfile> = config.get("profile.dev")?;
```
Supports environment variables when fetching structs or maps. Note that it can
support underscores in env var for struct field names, but not maps. So for
example, "opt_level" works, but not "serde_json" (example:
`CARGO_PROFILE_DEV_OVERRIDES_serde_OPT_LEVEL`). I don't have any ideas for a
workaround (though I feel this is an overuse of env vars).
It supports environment variables for lists. The value in the env var will get
appended to anything in the config. It uses TOML syntax, and currently only
supports strings. Example: `CARGO_FOO=['a', 'b']`. I did *not* modify
`get_list` to avoid changing behavior, but that can easily be changed.
Dimitri Wegner [Tue, 29 May 2018 08:46:10 +0000 (10:46 +0200)]
Compare pkg ids based on their encoding.
This comparison is needed, since we want to figure out which packages
are duplicate in the lockfile. Package coming from different
registries will be different in the lockfile, but not local packages
with the same name and version but different path.
bors [Mon, 28 May 2018 16:49:15 +0000 (16:49 +0000)]
Auto merge of #5587 - matklad:rustdoc-target, r=alexcrichton
Support `--target` argument in `cargo rustdoc`
We don't support `--target` in `cargo rustdoc`. Seems like an omission to me? We support it in `cargo rustc`. Discovered in https://github.com/rust-lang/cargo/pull/5543#issuecomment-392525154.
projects / cargo.git / log